Skip to content

fix(rig-acp): rig acp refuses an option after acp instead of ignoring it - #3142

Merged
gold-silver-copper merged 3 commits into
mainfrom
fix/acp-trailing-options
Nov 8, 2026
Merged

gold-silver-copper merged 3 commits into
mainfrom
fix/acp-trailing-options

Conversation

@gold-silver-copper

Copy link
Copy Markdown
Collaborator

fix(rig-acp): rig acp refuses an option after acp instead of ignoring it

Description

From the 2026-11-07 architecture audit (K3-A, f-1). Invocation::parse puts every word after a command into its arguments. rig-acp reads only the options before acp (Invoked::flag(TOOLS)) and never reads the arguments. So rig acp --tools=read started an ACP server whose sessions ran with every tool, not only the ones the user asked for, and nothing said so.

The router now refuses at startup when any word follows acp. It says why on stderr and exits with code 2, through the usual refuse_run path. An editor that launches rig acp --tools=read sees:

rig: rig acp takes nothing after `acp`, so `--tools=read` would be ignored; put options before `acp`, as in `rig --tools=read acp`.

Why in rig-acp, not the shared parser. rig acp takes no words, so refusing any word there leaves every other command's parsing as it is. Changing Invocation::parse to read options after a command would change all commands, and their words are the command's to read.

What users see change

  • rig acp --tools=read (or any word after acp) no longer starts an ACP server. It exits with code 2 and prints on stderr that nothing is taken after acp and options go before it, as in rig --tools=read acp.
  • rig --tools=read acp (options before acp) works as before.
Bug Test Fails on base
An option after acp is silently dropped rig-acp tests::an_option_after_acp_is_refused yes. The test app has no home or runtime, so on base the only refusal is for those (rig acp needs rig's home, …), never for the trailing option. At the head, the trailing option is refused first.

Changelog

  • (rig-acp) rig acp refuses any word after acp, such as rig acp --tools=read, saying to put options before acp, instead of ignoring it.

Migration

None. A command line that put options after acp was already ignoring them. It now has to put them before acp.

Type of change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Testing

  • cargo nextest run --locked --profile local -p rig-acp on box2: 37 of 37 passed
  • cargo clippy --locked -p rig-acp --all-targets -- -D warnings on box2: clean
  • cargo xtask verify --affected --base origin/main on box2: "All 10 checks passed"
  • The test fails on the test-only commit and passes at the head (box2)

Checklist:

  • I have updated READMEs and Rust docs affected by this change
  • I have added tests that prove my fix is effective or that my feature works
  • I did not edit CHANGELOG.md or MIGRATING.md (they are generated at release)

Notes

  • Production lines: +10 (plugins/rig-acp/src/router.rs). Test lines: +25.
  • Differs from the audit's prior art (f-1.diff): that test asked the shared parser to read the option as a flag or refuse it. This fix refuses in rig-acp, for the reason above.
  • rig acp --help is now refused the same way. Before, it was ignored and the server started.
  • Not verified: I did not launch rig acp --tools=read from a real editor. The refusal goes through the same refuse_run path (stderr, exit code 2) as rig-acp's other startup refusals.

Follow-ups

  • None.

@gold-silver-copper
gold-silver-copper added this pull request to the merge queue Nov 8, 2026
Merged via the queue into main with commit 5fde376 Nov 8, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant